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DETAILED ACTION 

A. The amendment filed on 1 3 March 2006 has been entered and fully considered. 

B. Claims 42-49 are cancelled by the amendment filed on 13 March 2006. Claims 
31-34 and 36-37 are cancelled by the amendment filed on 23 September 2005. 

C. Claims 1 -30, 35, 38-41 , and 50-58 are pending. 

Claim Rejections - 35 USC § 103 

1 . The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 

obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

2. Claims 1-7, 22-25, 30, 50, 51, and 56 are rejected under 35 U.S.C. 103(a) as 
being unpatentable over Tsukakoshi et al (US 6, 577, 634), hereinafter referred to as 
Tsukakoshi, in view of Ichinohe et al (US 6, 370, 653), hereinafter referred to as 
Ichinohe. 

Tsukakoshi discloses a router device with route calculation units and forwarding 

units. 

3. Regarding claim 1 , Tsukakoshi discloses a router device with route calculation 
units and forwarding units. The route calculation unit has a CPU and memory and has 
two or more routing protocol means to handle different types of protocols. Similarly the 
forwarding unit has a CPU as a forwarding processor and a memory unit. The router 
device's forwarding unit serves as the I/O unit and interfaces with external devices. The 
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routing calculation unit constitutes the routing layer while the forwarding unit defines the 
I/O layer. The router device disclosed by Tsukakoshi is in effect a clustered router and 
appears to other external routers and communication terminals as a single network 
forwarding apparatus. (See Column 3, Lines 62-67) 

Tsukakoshi discloses a router supporting multiple routing protocols (See Column 
3, Lines 18-20; Figure 1 element 15; Each routing calculation unit can handle two 
different routing protocols), the router comprising: 

a. an interface layer including a plurality of I/O controllers, each I/O controller 
implementing an I/O port; (See Figure 1, element 18; Figure 4, element 18;Column 4, 
Lines 53-64; Each forwarding unit acts as an I/O controller determining what to 
transmit, re-transmit, accept and reject from the incoming and outgoing packet 
traffic. Each forwarding unit has to have at least one I/O interface or port to send 
to and receive packets from external routers like router 25 in Figure 1); 

b. a switching layer in communication with the interface layer for selectively establishing 
signal pathways between I/O ports; (See Figure 4, element 46; Column 4, Line 40) 

c. a routing layer in communication with the interface layer, and the routing layer 
including a plurality of routing protocol computing entities, each routing protocol 
computing entity being associated with respective set of at least one routing protocol 
and including: (Tsukakoshi discloses each router entity 12 in Figure 1 contains two 
or more routing protocol means 15 as shown in Figure 1. See Column 3, Line 19. 
Further, Tsukakoshi shows that each router entity 12 in Figure 1 can contain 
more than two routing protocol means 15 which can easily be verified in Figure 3 
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that there are three running different protocols - protocol A, B, and C. See 
Column 2, Lines 37-38 and Column 14, Lines 13-20.) 

i. a respective CPU (See element 41, Figure 4); 

ii. a respective data storage medium in communication with the CPU (See 
element 42, Figure 4); 

iii. and storing program data executed by the CPU (it is inherent for any 
processor designed to execute a series of procedures to store the instructions 
for executing the procedures in memory and in this case the program data has to 
be stored in the storage medium shown in Figure 4 as element 42); 

d. to cause the routing protocol computing entity to effect management of one or more 
peering sessions with remote routing devices according to the at least one routing 
protocol in the set associated with the routing protocol computing entity. (Applicant on 
page 7, Line 6 of the specification defines peering session to be a communication 
session between two different routers. Tsukakoshi discloses the clustered router 
is seen as a single entity by external devices like router 25 in Figure 1. 
Tsukakoshi further discloses that a communication or peering session can be 
established between the clustered router and any device like router 25 to 
continuously exchange packets. Each router unit in the clustered router can 
have a peering session with remote devices using the first and/or second 
protocol means. See also Column 2, Lines 11-15; Column 3, Lines 62-67; and 
Column 4, Lines 1-5. It has already been established that Tsukakoshi's clustered 
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router device can run any subset of routing protocols from a common set of 
routing protocols used in the art of networking.) 

4. Regarding claim 23, Tsukakoshi discloses a router, comprising: 

a. an interface layer including a plurality of I/O controllers, each I/O controller 
implementing an I/O port (See Figure 1, element 18; Figure 4, element 18;Column 4, 
Lines 53-64; Each forwarding unit acts as an I/O controller determining what to 
transmit, re-transmit, accept and reject from the incoming and outgoing packet 
traffic. Each forwarding unit has to have at least one I/O interface or port to send 
to and receive packets from external routers like router 25 in Figure 1); 

b. a switching layer in communication with the interface layer for selectively establishing 
signal pathways between the I/O ports (See Figure 4, element 46; Column 4, Line 
40); 

C. a routing layer in communication with the interface layer, the routing layer including a 
plurality of routing protocol computing entities, each routing protocol computing entity 
being associated with a respective routing protocol (See Column 4, Lines 39-52) and 
including: 

i. a respective CPU (See element 41, Figure 4); 

ii. a respective data storage medium in communication with the CPU (See 
element 42, Figure 4); and storing program data for execution by the CPU (it is 
inherent for any processor designed to execute a series of procedures to store 
the instructions for executing the procedures in memory and in this case the 
program data has to be stored in the storage medium shown in Figure 4 as 
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element 42) to cause the routing protocol computing entity to effect management of one 
or more peering sessions with remote routing devices according to the routing protocol 
associated with the routing protocol computing entity (Tsukakoshi discloses the 
clustered router is seen as a single entity by external devices like router 25 in 
Figure 1. Tsukakoshi further discloses that a communication or peering session 
can be established between the clustered router and any device like router 25 to 
continuously exchange packets. Each router unit in the clustered router can 
have a peering session with remote devices using the first and/or second 
protocol means. See also Column 2, Lines 11-15; Column 3, Lines 62-67; and 
Column 4, Lines 1-5.), the management of one or more peering sessions comprising 
maintaining in the data storage medium one or more route databases (See Figure 1, 
elements 17; See Column 8, Lines 48-50 and Column 3, Lines 20-26; Tsukakoshi 
shows that each routing protocol means that runs a specific routing protocol 
during a peering session extracts specific network routing information and puts it 
in element 16 of Figure 1 and then creates a routing table). 
5. With respect to claims 1 and 23, Tsukakoshi fails to disclose a router having a 
set of routing protocol entities wherein each routing protocol entity is associated with a 
different routing protocol. 

Ichinohe discloses a router with several routing protocol processing units. 

Ichinohe teaches a router having a set of routing protocol entities wherein each 
routing protocol entity runs a different routing protocol. (See Column 4, Lines 4-7 and 
30-43. See also in Figures 1, 10, 12, and 14, processors 113, 114, 203, and 204 are 
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routing protocol entities and as illustrated in Column 5, Lines 27-31 the protocol 
OSPF is run on processors 114 and 204 and the protocol RIP is run on 
processors 113 and 203.) 

It would have been obvious to one having ordinary skill in the art at the time the 
invention was made to modify Tsukakoshi's clustered router to use routing protocol 
entities where each entity runs a different routing protocol. The motivation being it 
provides modularity by isolating a given protocol to a specific processor as further 
illustrated by Ichinohe in Column 2, Lines 22-27. 

6. Regarding claim 2, Tsukakoshi discloses a router wherein each routing protocol 
computing 

entity is operative to maintain simultaneously a plurality of peering sessions with remote 
routing devices. (Column 2, Lines 11-15; Column 3, Lines 62-67; and Column 4, 
Lines 1-5) 

7. Regarding claim 3, Tsukakoshi discloses a router wherein each routing protocol 
computing entity is operative to exchange data with a remote routing device through the 
I/O interface layer during a peering session. (Column 2, Lines 11-15; Column 3, Lines 
62-67; and Column 4, Lines 1-5) 

8. Regarding claim 4, Tsukakoshi discloses a router, wherein the peering session 
includes a transfer of route information data from the router to a remote routing device. 
(Column 2, Lines 11-15; Column 3, Lines 62-67; and Column 4, Lines 1-5) 
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9. Regarding claim 5, Tsukakoshi discloses a router, wherein the peering session 
includes a transfer of route information data from the remote routing device to the 
router. (Column 2, Lines 11-15; Column 3, Lines 62-67; and Column 4, Lines 1-5) 

10. Regarding claim 6, Tsukakoshi disclose a router, wherein the data storage 
medium (element 42 in Figure 4) of at least one of the plurality of routing protocol 
computing entities, stores a local routing table (element 17, in Figure 1) holding at 
least one inbound route database derived at least in part from route information data 
transferred from a remote routing device (element 25 in Figure 1) to the router. 
(Column 3, Lines 23-27;Column 4, Lines 44-52) 

1 1 . Regarding claim 7, Tsukakoshi discloses a router wherein at least one of the 
plurality of routing protocol computing entities is operative to apply an inbound policy 
processing on the route information data transferred from a remote routing device 
during generation of at least one inbound route database. (Column 3, Lines 23- 
27;Column 4, Lines 44-52; This is strictly a function of the routing protocol. This 
is implemented with a policy based routing protocol like BGP. Tsukakoshi's 
device can work with any routing protocol including BGP. Further Examiner 
takes Official Action on that a BGP is a policy based routing protocol.) 

12. Regarding claims 22, 50 and 51, Tsukakoshi discloses a router; wherein the 
subset of protocols associated with the first routing protocol computing entity is different 
from the subset of protocols associated with the second routing protocol and further 
discloses any protocol can be used and mentions the RIP protocol as an example. 
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(Column 3, Lines 18-23; Column 6, Lines 1-10; Tsukakoshi's router is not limited 
by the type of the routing protocol chosen.) 

Tsukakoshi, however, fails to expressly disclose that routing protocols can be 
OSPF and BGP. Further, Tsukakoshi fails to expressly disclose that only one routing 
protocol can run on a protocol computing entity. Even further, Tsukakoshi's fails to 
disclose two protocol computing entities can have mutually exclusive sets of protocols. 

Ichinohe discloses that routing protocols can be OSPF and BGP. Ichinohe 
discloses that only one routing protocol running on a protocol computing entity. 
Ichinohe discloses two protocol computing entities can have mutually exclusive sets of 
protocols (See Column 54, Lines 4-7 and 30-43 and Column 5, Lines 20-27. See 
also in Figures 1, 10, 12, and 14, processors 113, 114, 203, and 204) 

It would have been obvious to one having ordinary skill in the art at the time the 
invention was made to modify Tsukakoshi's clustered router to use OSPF and BGP as 
routing protocols. The motivation being it provides peering sessions with networks 
based on these protocols and such sessions with these networks are beneficiary as 
theses networks running OSPF and BGP protocols are widely deployed and make up 
part of what is known as the Internet. 

13. Regarding claims 24, 30, and 56, Tsukakoshi discloses a router, wherein the 
first routing protocol and the second routing protocol are distance vector protocols. 
(Column 3, Lines 18-23; Column 6, Lines 1-10; Tsukakoshi's router is not limited 
by the type of the routing protocol chosen.) 
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14. Regarding claim 25, Tsukakoshi discloses a router, wherein the first routing 
protocol and the second routing protocol are link state protocols. (Column 3, Lines 18- 
23; Column 6, Lines 1-10; Tsukakoshi's router is not limited by the type of the 
routing protocol chosen.) 

15. Claims 8-21, 52-55, 57, and 58 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Tsukakoshi in view of Ichinohe as applied to claim 5 above, and 
further in view of Basso et al (US 7, 003, 582), hereinafter referred to as Basso. 

16. Regarding claim 8, the combination of Tsukakoshi and Ichinohe discloses a 
router wherein the data storage medium of at least one of the plurality of routing 
protocol computing entities stores a routing table that holds a best route database, at 
least one routing protocol computing entity being operative to apply an outbound policy 
processing on its best route database to generate at least one outbound route 
database, at least one routing protocol computing entity being operative to transfer 
route information data from the outbound route database to a remote routing device. 
(Tsukakoshi Column 3, Lines 23-27;Column 4, Lines 44-52;This is strictly a 
function of the routing protocol. This is best implemented with a policy based 
routing protocol like BGP. Tsukakoshi's device can work with any routing 
protocol including BGP. Further Examiner takes Official Action on that a BGP is a 
policy based routing protocol. ) 

17. Regarding claim 9, the combination of Tsukakoshi and Ichinohe discloses, 
wherein the data storage medium (element 42, Figure 4) of each routing protocol 
computing entity stores a routing table (element 17, Figure 1) holding at least one 
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inbound route database derived from route information data transferred from a remote 
routing device (Tsukakoshi element 25, Figure 1) to the router. (Column 3, Lines 23- 
27, Column 4, Lines 44-52) 

18. Regarding claim 10, the combination of Tsukakoshi and Ichinohe discloses a 
router, wherein each routing protocol computing entity is operative to apply an inbound 
policy processing on the route information data transferred from a remote routing device 
during generation of at least one inbound route database. (Tsukakoshi Column 3, 
Lines 23-27;Column 4, Lines 44-52;This is strictly a function of the routing 
protocol. This is implemented with a policy based routing protocol like BGP. 
Tsukakoshi's device can work with any routing protocol including BGP. Further 
Examiner takes Official Action on that a BGP is a policy based routing protocol. ) 

19. Regarding claim 11, the combination of Tsukakoshi and Ichinohe discloses a 
router, wherein the routing table of the routing protocol computing entity holds a best 
route database, the routing protocol computing entity being operative to apply an 
outbound policy processing on the best route database to generate at least one 
outbound route database, each routing protocol computing entity being operative to 
transfer route information data from the outbound route database to a remote routing 
device. (Tsukakoshi Column 3, Lines 23-27;Column 4, Lines 44-52; This is strictly 
a function of the routing protocol. This is best implemented with a policy based 
routing protocol like BGP. Tsukakoshi's device can work with any routing 
protocol including BGP.) 
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20. With respect to claims 8, 9, 10, and 11, the combination of Tsukakoshi and 
Ichinohe fails to expressly teach a router that has a routing protocol computing entity 
with its own local routing table. 

Basso teaches a scalable router. 

Basso teaches a router that has a routing protocol computing entity with its own 
local routing table. (See Figure 2, element 28 and Column 3, Lines 22-25) 

It would have been obvious to one having ordinary skill in the art at the time the 
invention was made to modify the combination of Tsukakoshi's and Ichinohe's router by 
using a routing protocol computing entity with its own local routing table. The motivation 
being it further enhances modularity by isolating a given protocol to a specific processor 
and limits the failure recovery impact of the computing means in that only the local data 
associated with the computing entity is rebuilt as detailed in Basso in Column 3, Lines 
44-49. 

21 . Regarding claim 12, Tsukakoshi discloses, wherein the routing layer includes a 
control computing entity in data communicative relationship with each routing protocol 
computing entity (See Column 4, Lines 39-52), and the control computing entity 
includes: 

a. a CPU (See element 41 in Figure 4); 

b. a data storage medium in communication with the CPU (See element 42 in 
Figure 4); 

C. a program data for execution by the CPU(it is inherent for any processor 
designed to execute a series of procedures to store the instructions for the 
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program executions in memory and in this case the program data has to be 
stored in the storage medium shown in Figure 4 as element 42); 
d. a master routing table stored in the data storage medium (See element 17 in Figure 
1; Column 4, Lines 50-52). 

22. Regarding claim 13, Tsukakoshi discloses a router, wherein the program data 
stored in the data storage medium of the control computing entity implements a routing 
table manager for managing the master routing table. (It is inherent for any processor 
designed to execute a series of procedures to store the instructions for the 
program executions in memory and in this case the program data has to be 
stored in the storage medium shown in Figure 4 as element 42. The routing table 
has to be managed by the program data to determine when to read from and write 
to the table) 

23. Regarding claim 14, Tsukakoshi discloses a router, wherein each routing 
protocol computing entity is in communication with the control computing entity to 
transfer to the data storage medium of the control computing entity data from at least 
one inbound route database in the routing protocol computing entity. (Column 3, Lines 
18-27) 

24. Regarding claim 15, Tsukakoshi discloses a router, wherein the routing table 
manager is operative to apply a master policy processing on data received from the 
inbound route database in each routing protocol computing entity to generate the 
master routing table. (Column 3, Lines 31-57; In Tsukakoshi's clustered router each 
routing table is a master routing table as each table gets updated with new route 
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info using the NISP protocol. In case of failure the routing table located in the 
backup unit will be up to date when the unit is activated) 

25. Regarding claim 16, Tsukakoshi discloses a router, wherein the master policy 
processing includes merging the data in the inbound route databases from at least two 
of the routing protocol computing entities to produce merged inbound routing data. (If 
the routing protocol is the same for the two entities then the data has to be 
merged and if the protocols are different the occurrence of a uniform merging is 
not necessarily true. This is also a function of policy based routing protocols like 
the BGP.) 

26. Regarding claim 17, Tsukakoshi discloses a router, wherein the merged inbound 
routing data includes information mapping destinations and routes to the destinations. 
(Column 3, Lines 23-27; This is standard information contained in most routing 
data.) 

27. Regarding claim 18, Tsukakoshi discloses a router, wherein the merged inbound 
routing data includes a plurality of destinations and a set of routes associated with each 
destination of the plurality of destinations, the master policy processing includes 
discarding from each set of routes a plurality of routes and retaining only a subset of the 
set of routes. (This is strictly a function of the routing protocol chosen. 
Tsukakoshi's clustered can accommodate any routing protocol. For instance 
BGP is a policy based routing protocol that selects best routes on the values of 
the BGP attributes and Examiner takes Official Action on this issue.) 
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28. Regarding claim 19, Tsukakoshi discloses a router, wherein the control 
computing entity is operative to transfer to the data storage medium of the first one of 
the routing protocol computing entities at least a portion of the master routing data to 
form the best route database in the data storage medium of the first routing protocol 
computing entities. (See Column 3, Lines 18-20; Note that determining the best 
route is a function of the routing protocol like BGP and not the actual router) 

29. Regarding claim 20, Tsukakoshi discloses a router, wherein the control 
computing entity is operative to transfer to the data storage medium of a second one of 
the routing protocol computing entities at least a portion of the master routing data to 
form the best route database in the data storage medium of the second one of the 
routing protocol computing entities. (See Column 3, Lines 18-20; Note that 
determining the best route is a function of the routing protocol like BGP and not 
the actual router.) 

30. Regarding claim 21, Tsukakoshi discloses a router, wherein each I/O controller 
includes a forwarding processor, when a data packet is received at the I/O controller, 
the forwarding processor determines an I/O port of the interface layer through which the 
data packet is to be released, where the forwarding processor including a data storage 
medium holding a forwarding table, and the forwarding table includes data derived from 
the master routing table. (Column 4, Lines 53-64) 

31 . Regarding claims 52 and 54, the combination of Tsukakoshi and Ichinohe 
discloses a router layer, comprising: a control computing entity in data communicative 
relationship with each routing protocol computing entity, the computing entity including: 
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i. a CPU(See Tsukakoshi element 41, Figure 4); 

ii. a data storage medium in communication with the CPU of the control 
computing entity(See Tsukakoshi element 42, Figure 4); 

iii. a master routing table stored in the data storage medium of the control 
computing entity, where the master routing table holding a master routing 
database derived at least in part from the inbound routing database of the first 
routing protocol computing entity and from the inbound routing database of the 
second routing protocol computing entity(See Tsukakoshi element 17 in Figure 
1; Column 4, Lines 50-52; Column 3, Lines 20-30 and Column 10, Lines 20- 
25); 

iv. program data in the data storage medium of the control computing entity for 
execution by the CPU of the control computing entity to implement a main 
routing table manager to manage the master routing table (it is inherent for any 
processor designed to execute a series of procedures to store the 
instructions for the program executions in memory and in this case the 
program data has to be stored in the storage medium shown in Figure 4 as 
element 42. The routing table has to be managed by the program data to 
determine when to read from and write to the table. However, Ichinohe 
teaches expressively a routing table manager in Figure 1 with elements 103 
and 104. ); 

a backup computing entity, in data communicative relationship with the first and second 
routing protocol computing entities and with the control computing entity (See 
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Tsukakoshi Figure 18; Column 10, Lines 6-25), and the backup computing entity 
includes: 

i. a CPU(See element 41, Figure 4); 

ii. a data storage medium in communication with the CPU of the backup 
computing entity(See element 42, Figure 4); 

iii. program data in the data storage medium of the backup computing entity for 
execution by the CPU of the backup computing entity to implement a main 
routing table manager (it is inherent for any processor designed to execute a 
series of procedures to store the instructions for the program executions in 
memory and in this case the program data has to be stored in the storage 
medium shown in Tsukakoshi Figure 4 as element 42. The routing table 
has to be managed by the program data to determine when to read from 
and write to the table); 

iv. the backup computing entity being responsive to an operational failure of the 
control computing entity (See Tsukakoshi Column 10, Lines 30-60) to: 

1. download the inbound routing databases from each routing protocol 
computing entities(Tsukakoshi Column 10, Lines 48-53); 

2. re-build the master routing database at least in part from the inbound 
routing databases downloaded from each routing protocol computing 
entities (See Tsukakoshi Column 10, Lines 53-57). 

32. Regarding claims 53 and 55, the combination of Tsukakoshi and Ichinohe 
discloses a router layer, comprising: a control computing entity in data communicative 
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relationship with each routing protocol computing entity, the computing entity including: 
(See Tsukakoshi Column 4, Lines 39-52) 

i. a respective CPU (See Tsukakoshi element 41, Figure 4); 

ii. a respective data storage medium in communication with the CPU(See 
Tsukakoshi element 42, Figure 4); 

iii. a master routing table stored in the data storage medium of the control 
computing entity, where the master routing table holding a master routing 
database derived at least in part from the inbound routing database of the first 
routing protocol computing entity and from the inbound routing database of the 
second routing protocol computing entity(See Tsukakoshi element 17 in Figure 
1; Column 4, Lines 50-52; Column 3, Lines 20-30 and Column 10, Lines 20- 
25); 

a backup computing entity, in data communicative relationship with the first and second 
routing protocol computing entities and with the control computing entity (See 
Tsukakoshi Figure 18; Column 10, Lines 6-25), and the backup computing entity 
includes: 

i. a CPU(See Tsukakoshi element 41, Figure 4); 

ii. a data storage medium in communication with the CPU of the backup 
computing entity(See Tsukakoshi element 42, Figure 4); 

iii. the backup computing entity being responsive to an operational failure of the 
control computing entity (See Tsukakoshi Column 10, Lines 30-60) to: 
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1 . transfer information from the master routing table to the data storage 
medium of the backup computing entity to re-build at least partially the 
local routing table of the first routing protocol computing entity(See 
Column 10, Lines 33-36; Tsukakoshi discloses that the active-state 
route calculation unit sends update information to the backup-state 
route calculation unit. When the backup-state becomes active it is 
able to re-build the routing table as it has all the necessary updates 
till the last moment before the active unit failed. Also worth noting 
that in Tsukakoshi's system the active unit routing table and the 
backup unit routing table are always synchronized and up to date 
and can all be considered as the universal master routing tables.) 

2. enable the program data in the data storage medium of the backup 
computing entity to effect management of one or more peering sessions 
with remote routing devices according to a first routing protocol. (It has 
already been established by Tsukakoshi that the clustered router can 
have a peering session with remote devices using the first and/or 
second protocol means. The backup computing entity will not 
establish any peering session when it is on stand by mode as it is a 
spare entity. However, once the backup unit becomes an active 
computing entity it can readily establish a peering session with 
external devices using steps taught by Tsukakoshi. See also 
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Column 2, Lines 11-15; Column 3, Lines 62-67; Column 4, Lines 1-5; 
Column 10, Lines 6-25); 

33. With respect to claims 52-55, the combination of Tsukakoshi and Ichinohe fails 
to expressly teach a router that has a routing protocol computing entity with its own local 
routing table. 

Basso teaches a router that has a routing protocol computing entity with its own 
local routing table. (See Figure 2, element 28 and Column 3, Lines 22-25) 

It would have been obvious to one having ordinary skill in the art at the time the 
invention was made to modify the combination of Tsukakoshi's and Ichinohe's router by 
using a routing protocol computing entity with its own local routing table. The motivation 
being it further enhances modularity by isolating a given protocol to a specific processor 
and limits the failure recovery impact of the computing means in that only the local data 
associated with the computing entity is rebuilt as detailed in Basso in Column 3, Lines 
44-49. 

34. Regarding claims 57 and 58, Tsukakoshi discloses a router wherein the routing 
protocol associated with the first one of the routing protocol computing entities is the 
same as the routing protocol associated with the second one of the routing protocol 
computing entities. (Column 3, Lines 18-23; Column 6, Lines 1-10; Tsukakoshi's 
router is not limited by the type of the routing protocol chosen.) 

35. Claims 26-29 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Tsukakoshi in view of Ichinohe as applied to claim 23 above, and further in view of 
Anderson et al (US Pub. 2003/0014665), hereinafter referred to as Anderson. 
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36. Regarding claim 26, the combination of Tsukakoshi and Ichinohe discloses all 
aspects of the claimed invention as set forth in the rejection of claim 24 but does not 
disclose how at least one of the remote devices forming a peering session with the first 
routing protocol computing entity can be prevented from forming any peering session 
with the second routing protocol entity. 

Anderson teaches how to provide a secure and automated response to a denial 
of service attacks in a router 

Anderson discloses how the Border Gateway Protocol security features allow a 
router to implement authenticating and filtering mechanism, wherein the first routing 
protocol computing entity is capable of establishing peering sessions with a first set of 
remote routing devices, the second routing protocol computing entity is capable of 
establishing peering sessions with a second set of remote routing devices, the first set 
of remote routing devices excluding at least one routing device that belongs to the 
second set of routing devices. (See Figure 4, element 340 and see paragraphs 40-42 
and 50-53. Anderson establishes how authentication and filtering can be 
implemented at the routing protocol level using features of BGP and DDOS 
squelch protocols.) 

37. Regarding claim 27, the combination of Tsukakoshi and Ichinohe discloses the 
aforementioned invention but does not disclose how the remote devices forming a 
peering session with the first routing protocol computing entity can be prevented from 
forming any peering session with the second routing protocol entity. 
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Anderson discloses how the Border Gateway Protocol security features allow a 
router such that the first set of remote routing devices forming a peering session can 
exclude any remote routing device from the second set. (See Figure 4, element 340 
and see paragraphs 40-42 and 50-53. Anderson establishes how authentication 
and filtering can be implemented at the routing protocol level using features of 
BGP and DDOS squelch protocols.) 

38. Regarding claim 28, the combination of Tsukakoshi and Ichinohe discloses the 
aforementioned invention but does not disclose how the remote devices forming a 
peering session with the first and second routing protocol computing entity can be 
mutually exclusive sets. 

Anderson discloses how the Border Gateway Protocol security features allows a 
router such that the first set of remote routing devices forming a peering session can be 
mutually exclusive with the second set. (See Figure 4, element 340 and see 
paragraphs 40-42 and 50-53. Anderson establishes how authentication and 
filtering can be implemented at the routing protocol level using features of BGP 
and DDOS squelch protocols.) 

39. Regarding claim 29, the combination of Tsukakoshi and Ichinohe discloses the 
aforementioned invention but does not disclose how the remote devices from different 
areas forming a peering session with the first and second routing protocol computing 
entity can be mutually exclusive sets. 

Anderson discloses how the Border Gateway Protocol security features allow a 
router such that the first routing protocol computing entity is capable of establishing 
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peering sessions with remote routing devices from a first area, the second routing 
protocol computing entity is capable of establishing peering sessions with remote 
routing devices from a second area, the first area being different from the second area. 

(See Figure 4, element 340 and see paragraphs 40-42 and 50-53. Anderson 
establishes how authentication and filtering can be implemented at the routing 
protocol level using features of BGP and DDOS squelch protocols. BGP is a real 
inter-autonomous system routing protocol. That is, it specifies how routing 
information is exchanged both between two computing entities running BGP 
protocol in different autonomous systems, and also between two computing 
entities within a single autonomous system. Therefore, the first set of remote 
routing devices can belong to one autonomous system and the second set can 
belong to a different autonomous system allowing BGP to enforce the exclusion. 
In addition Anderson teaches that DDOS squelch protocol can be used for 
authentication and filtering.) 

40. With respect to claims 26-29, it would have been obvious to one having ordinary 
skill in the art at the time the invention was made to modify the combination of 
Tsukakoshi's and Ichinohe's routers to use the Border Gateway Protocol with the 
advanced security features as the routing protocol, the motivation being BGP V-4 has 
been widely adopted as the protocol for inter-autonomous communications. 

41. Claim 35 is rejected under 35 U.S.C. 103(a) as being unpatentable over 
Tsukakoshi et al (US 6, 577, 634), hereinafter referred to as Tsukakoshi, in view of 
Anderson et al (US Pub. 2003/0014665), hereinafter referred to as Anderson. 
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Tsukakoshi teaches a router, comprising: 

a. an interface layer including a plurality of I/O controllers, each I/O controller 
implementing an I/O port_(See Figure 1, element 18; Figure 4, element 18;Column 4, 
Lines 53-64; Each forwarding unit acts as an I/O controller determining what to 
transmit, re-transmit, accept and reject from the incoming and outgoing packet 
traffic. Each forwarding unit has to have at least one I/O interface or port to send 
to and receive packets from external routers like router 25 in Figure 1); 

b. a switching layer (See Figure 1, element 13 and Figure 4, element 46) in 
communication with the interface layer for selectively establishing signal pathways 
between the I/O ports (See Figure 1, element 13; Figure 4, elements 18 and 46; See 
Column 4, Lines 39-43 to see how the switch layer interfaces with the forwarding 
units that act as I/O controllers. Column 4, Lines 53-64 indicates that each 
forwarding unit acts as an I/O controller determining what to transmit, re-transmit, 
accept and reject from the incoming and outgoing packet traffic. Each forwarding 
unit has to have at least one I/O interface or port to send to and receive packets 
from external routers like router 25 in Figure 1); 

c. a routing layer (Figure 1, element 20) in communication with the interface layer 
(Figure 1, element 18), the routing layer being capable of managing at least one 
peering session with a remote routing device, (See Figures 10-13) the peering session 
including the exchange of messages with the remote routing device through one of the 
I/O controllers (Figure 2 and Column 3, Lines 58-67), the peering session being 
comprised of plurality of tasks_(See Figure 3 and Column 4, Lines 13-38); 
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d. the one I/O controller implementing a peer session assist module, (This limitation is 
inherent because Tsukakoshi discloses like any router uses its Forwarding Unit 
that act as I/O controller to communicate with another remote router and there 
has to be peering session assist modules.) 

e. the peering session assist module being capable of performing some of the tasks of 
the peering session autonomously from the routing layer, (This limitation is true in 
Tsukakoshi's system because the routing layer (Figure 1, element 20) and the I/O 
controller (i.e. Forwarding Units - Figure 1, element 18) are independent entities) 

f. the routing layer being capable of performing tasks of the peering session other than 
the tasks performed by the peering session assist module. (This limitation is true in 
Tsukakoshi's system because the routing layer (Figure 1, element 20) and the I/O 
controller (i.e. Forwarding Units - Figure 1, element 18) are independent entities) 

Tsukakoshi does not disclose the tasks performed by the peering session assist 
module include authenticating messages received from the remote routing device. 

Anderson discloses how the Border Gateway Protocol security features allow a 
router such that the tasks performed by the peering session assist module include 
authenticating messages received from the remote routing device. 

It would have been obvious to one having ordinary skill in the art at the time the 
invention was made to modify Tsukakoshi's clustered router to use the Secure Border 
Gateway Protocol with the advanced security features as the routing protocol to 
facilitate authenticating messages received from the remote routing device, the 
motivation being to minimize security vulnerabilities. 
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42. Claims 38 and 41 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Tsukakoshi et al (US 6, 577, 634), hereinafter referred to as Tsukakoshi, in view of 
Fukushima et al (US 6, 049, 524), hereinafter referred to as Fukushima and Basso et al 
(US 7, 003, 582), hereinafter referred to as Basso. 

43. Regarding claim 38, Tsukakoshi teaches a router, comprising: 

a. an interface layer including a plurality of I/O controllers, each I/O controller 
implementing an I/O port (See Figure 1, element 18; Figure 4, element 18;Column 4, 
Lines 53-64; Each forwarding unit acts as an I/O controller determining what to 
transmit, re-transmit, accept and reject from the incoming and outgoing packet 
traffic. Each forwarding unit has to have at least one I/O interface or port to send 
to and receive packets from external routers like router 25 in Figure 1); 

b. a switching layer in communication with the interface layer for selectively establishing 
signal pathways between the I/O ports (See Figure 1, element 18; Figure 4, element 
18;Column 4, Lines 53-64; Each forwarding unit acts as an I/O controller 
determining what to transmit, re-transmit, accept and reject from the incoming 
and outgoing packet traffic. Each forwarding unit has to have at least one I/O 
interface or port to send to and receive packets from external routers like router 
25 in Figure 1); 

c. a routing layer in communication with the interface layer (See Column 4, Lines 39- 
52); 

Tsukakoshi, however, fails to expressly disclose that a routing protocol 
implemented in a route calculating entity can be a Link State protocol. 
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Basso teaches that a routing protocol implemented in a route calculating entity 
can be a Link State protocol. (OSPF is a link state protocol and is shown in Figure 
2, element 26. See also Column 3, Lines 22-25) 

It would have been obvious to one having ordinary skill in the art at the time the 
invention was made to modify Tsukakoshi's clustered router to use routing protocol 
entities where each entity runs a link state protocol such as OSPF. The motivation 
being it provides modularity by isolating a given protocol to a specific processor and 
OSPF is the most widely deployed link state protocol. 

Tsukakoshi, however, fails to disclose I/O controller implementing an LSA entity 
including an LS database. 

Fukushima teaches a multiplex router device, shown in figure 2, and it is identical 
to that of Tsukakoshi's clustered router device, which is shown in Figure 14. Fukushima 
teaches that his system can implement Link State protocol as one of the routing 
protocols and is indicated by element 22 in Figure 2. (See also Column 5, Lines 50-75 
and Column 6, Lines 1-5) 

Fukushima discloses each I/O controller (i.e. Forwarding Unit) implements an 
LSA entity, where the LSA entity includes an LS database (See Element 19 in Figure 
2; Column 6, Lines 7-11; Since Fukushima teaches that the routing protocol is a 
link state protocol there has to be an LSA entity in both the router and I/O 
Controller layer), and the LSA entity is responsive to an LSA message from a remote 
routing device (Column 1, Lines 53-57) including LS information to: 

i. update the LS database (Column 1, Lines 66-67 and Column 2, Lines 1-7); 
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ii. forward the LS information to the routing layer (Column 2 Lines 1-20 and 32- 

43); 

It would have been obvious to one having ordinary skill in the art at the time the 
invention was made to modify Tsukakoshi's clustered router to use the link state 
protocol as the routing protocol with the I/O controller implementing an LSA entity 
including an LS database, the motivation being to minimize the amount of information 
being sent to the standby mode routing calculation unit. If the link state protocol is used 
as the routing protocol then only the link state information can be sent to the routing 
calculation unit in standby mode thereby minimizing internal traffic between the active 
and standby units as further discussed in Fukushima Column 4, Lines 34-38. 
44. Regarding claim 41 , Tsukakoshi teaches all aspects of the claimed invention as 
set forth in the rejection of claim 38 but fails to teach a routing layer that includes a main 
control computing entity and a backup computing entity with each entity with its own 
routing table manager. 

Fukushima teaches a routing layer that includes a main control computing entity 
and a backup computing entity with each entity with its own routing table manager. 
Specifically Fukushima teaches a router, wherein the routing layer includes: 
a. a control computing entity in data communicative relationship with each I/O controller 
(element 13 in Figure 14), where the control computing entity(element 1 1 in Figure 
14), includes: 

i. a CPU (element 40 in Fig. 14); 
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ii. a data storage medium in communication with the CPU (element 41 in Figure 
14); 

iii. a master routing table stored in the data storage medium, where the master 
routing table holding a master routing database derived at least in part from the 
LS database of at least one of the I/O controllers (elements 19 in Figure 2; 
Column 2, Lines 4-7 and 40-42; Column 5, Lines 51-67 and Column 6, Lines 
1-11); 

iv. a program data in the data storage medium to implement a main routing table 
manager to manage the master routing table (element 18 in Figure 2; Column 5, Line 
66); 

b. a backup computing entity in data communicative relationship with at least one of the 
I/O controller, where the backup computing entity (Column 7, Lines 30-45; 
Fukushima discloses that the backup or standby computing entity is identical to 
the active entity shown in Figure 2. Therefore the active and backup entities have 
identical hardware setup.) including: 

i. a CPU (element 40 in Fig.14); 

ii. a data storage medium in communication with the CPU of the backup 
computing entity; (element 41 in Fukushima's figure 14); 

iii. program data in the data storage medium of the backup computing entity for 
execution by the CPU of the backup computing entity to implement a main 
routing table manager (element 18 in Fukushima's Figure 2; Column 5, Line 
66); 
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iv. the backup computing entity being responsive to an operational failure of the 
control computing entity (Column 7, Lines 46-52) to: 

1. transfer information from at least one of the I/O controllers to re-build 
the LS database (Column 7, Lines 53-67); 

2. enable the program data in the data storage medium of the backup 
computing entity to act as a main routing table manager (Column 7, Lines 
46-52; Once the standby unit becomes active it becomes the main 
routing table manager 

It would have been obvious to one having ordinary skill in the art at the time the 
invention was made to modify Tsukakoshi's clustered router to use a routing layer that 
includes a main control computing entity and a backup computing entity with each entity 
with its own routing table manager, the motivation being minimizing communication 
disruptions when a computing entity experiences failure. 

45. Claims 39 and 40 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Tsukakoshi, in view of Fukushima and Basso as applied to claim 38, in further view 
of Zinin et al (US 6, 820, 134), hereinafter referred to as Zinin. 

46. Regarding claim 39, the combination of Tsukakoshi, Basso, and Fukushima 
teaches all aspects of the claimed invention as set forth in the rejections of claim 38 
including the existence of an LSA entity. However the modified invention of Tsukakoshi, 
Basso, and Fukushima fails to teach that, the router upon receiving an LSA message, it 
will verify whether the LS information is present or not in the LS database and 
consequently takes appropriate action. 
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Zinin teaches that when an entity receives an LSA message then it needs to 
check whether the LS information is present or not in the LS database and update the 
database if the info exists or discard the LSA if the info already exists in the LS 
database. (Column 8, Lines 59-60 and Column 11, Lines 5-10) 

It would have been obvious to one having ordinary skill in the art at the time the 
invention was made to modify the modified invention of Tsukakoshi's, Basso's and 
Fukushima's clustered router to use the link state protocol as the routing protocol and 
verify if the LS information is present in the LS database, the motivation being 
minimizing the amount of information being sent to the router. If the link state protocol 
is used as the routing protocol then only the link state information can be sent to the 
routing calculation unit in standby mode thereby minimizing internal traffic between the 
active and standby units. Also it allows an efficient flooding system resulting in 
conserving bandwidth and speeding the router. 

47. Regarding claim 40, the modified invention of Tsukakoshi, Basso, and 
Fukushima as taught above disclosed the aforementioned invention including the 
existence of an LSA entity. It also disclosed that the LSA entity (LSA entity is simply 
the ability to handle LS protocol at the forwarding unit) is responsive to LS 
information received from any I/O controller (i.e. forwarding unit) and being able to 
transmit the LSA message including the LS information to a remote routing device. 
(Fukushima, Column 7, Lines 30-45) 

Response to Arguments 
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48. Applicant's arguments filed on 13 March 2006 have been fully considered but 
they are not persuasive. 

49. Applicant's arguments with respect to independent claims 1 and 23 in Section B 
of the Remarks, dependent claim 22 in Section C of the Remarks, and dependent 
claims 26-29 in Section D of the Remarks have been considered but are moot in view of 
the new ground(s) of rejection. Specifically Basso and Ichinohe teach a scalable router 
where each protocol computing entity can have a unique protocol. 

50. Applicant's arguments with respect to independent claim 35 in Section E of the 
Remarks have been considered but are moot in view of the new ground(s) of rejection. 
Specifically Anderson teaches authenticating and filtering from the routing layer using 
different protocols including BGP. 

51 . Applicant's arguments with respect to claims 38 and 41 in Section F of the 
Remarks have been considered but are moot in view of the new ground(s) of rejection. 
Specifically Basso now teaches a link state protocol can independently be run on a 
protocol computing entity. Applicant correctly points out on page 31 in lines 7-8 of the 
Remarks that Fukushima describes a Link State Database in the routing layer 
maintained by the routing calculation unit. However, Applicant argues that Fukushima 
forwarding process units fails to maintain an LS database as claimed in claim 38. 
Examiner respectfully disagrees with Applicant's position. Fukushima shows a routing 
table 19 in Figure 2 located in the forwarding process units. The routing table 19 is 
populated from the LS DB 22 in the routing layer. Since the routing table is effectively a 
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database and contains Link State information derived from the routing layer, the routing 
tables in the forwarding process units can be viewed as a Link State DB. 

Conclusion 

The prior art made of record and not relied upon is considered pertinent to 
applicant's disclosure. 

The following US and European Patent Application describes a multiple virtual 
router with a controlling entity: 

European Patent Application (EP 0 926 859 A2) to Scott et al 

US Pub. No. (2002/0141378) to Bayes et al 

The following US Patent describes policy management: 

US Patent (5, 889, 953) to Thebaut et al. 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Habte Mered whose telephone number is 571 272 6046. 
The examiner can normally be reached on Monday to Friday 9:30AM to 5:00PM. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Hassan Kizou can be reached on 571 272 3088. The fax phone number for 
the organization where this application or proceeding is assigned is 571-273-8300. 
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Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). 
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